Conventionally, from a synchronization standpoint, a fixed relationship has been implemented between client and server, and so synchronization of data has been hardwired and dedicated between the client and server with limitations on flexibility and scalability as a result. Additionally, where a client may become disconnected from the server, due to network unavailability, power loss, or some other reason, there should also be a way to proceed despite the disconnection, i.e., when a client application is off-line from a main server. Today, as between the single client and server, this off-line behavior is either unavailable, or fixed, i.e., performed according to static behavior that also has limitations on flexibility and scalability.
Moreover, conventionally, these dedicated synchronization relationships, whether offline or online, suffer from the complexity of the synchronization data types maintained and utilized when communicating synchronized data according to fixed and rigid synchronization frameworks, which are often dependent on particular database formats being present in storage giving rise to synchronization incompatibility issues. Complicating matters, assurance of proper synchronization and replication becomes especially complex when multiple clients are allowed to come in and out of contact with the server, often at too great a cost to the server maintaining synchronization relationships with all of the clients.
Generally speaking, occasionally connected applications are defined as applications that connect to a remote data source, such as a database, web service, etc. to read/write data that is desired for the functioning of the application. Additionally, these applications have a requirement to continue to work seamlessly even when they are offline, i.e., not connected to the remote data source. The reason to work offline can be unavailability of network or for better data-access performance.
Existing systems for building applications for synchronizing relational data include remote data access (RDA), Merge Replication and ADO.NET DataSets. However, RDA and Merge Replication provide end-to-end solutions as opposed to building blocks and are tied to the data store formats on both server and client sides. For another example of a limitation on existing systems, RDA can only be used when the client is Microsoft's SQL Server Compact Edition and the server is Microsoft SQL Server. Additionally, while ADO.NET disconnected DataSets are not bound to the store, they have other limitations like their requirement of being loaded entirely in memory without any ability to download incremental changes from the server.
Thus, existing solutions are at opposite ends of the spectrum. At one end, solutions like RDA and ADO.NET are simple, but they have very limited features, e.g., these do not support downloading incremental data. In this regard, sending all the data from server to client for every synchronization can be expensive especially over slow links. RDA also requires the client database to be a SQL client and DataSets are not backed by a client database so they lack efficient query capabilities of the cache. And on the other end of the spectrum, solutions like Merge replication, while providing rich features like dynamic filtering and logical records, are overly complex and rigid, providing the developer very little flexibility to customize the solution to fit their own needs. With solutions like Merge, the developer gets all or nothing. Accordingly, what is desirable is a generalizable synchronization framework including building blocks for building customized synchronization applications that suit the functionality and context of the application being deployed.
Today, to the extent that any systems have attempted to address synchronization to multiple clients, the solutions have been limited to replication of a whole set of database information to all of the clients, and there has been no way to selectively synchronize one or more subsets of the database information, e.g., in the event that a client may wish to just synchronize with a small portion of the relevant data. For instance, a client may wish to retrieve only the last month of email, as opposed to the whole email database file, but today, there is no way to arbitrarily or dynamically limit or filter the data that is synchronized between client and server without reconfiguring synchronization to synchronize another set of data in a new static fashion.
Thus, to synchronize data of a data store from a server to several clients, and vice versa, synchronization and replication of updates, or changes, must take place among the various devices. Accordingly, what is desired is a synchronization framework that addresses each of the above-identified problems in the state of the art of synchronization and replication of data between a server and loosely coupled clients. For instance, a framework is desirable that makes it simple for application developers by implementing components that are able to work with and process concepts and data types with which developers are already familiar. In addition, a synchronization framework is desired that enables a highly scalable server for a variety of loosely coupled devices as they come into and out of contact with the server, and that operates independent of database format.
Accordingly, in consideration of the lack of sophistication of the current state of the art of synchronization of data between a server and loosely coupled clients, it would be desirable to provide an improved synchronization framework for servers and clients. These and other deficiencies in the state of the art of synchronization in the context of loosely coupled devices will become apparent upon description of the various exemplary non-limiting embodiments of the invention set forth in more detail below.